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THE REPLY FILED 16 July 2004 FAILS TO PLACE THIS APPLICATION IN CONDITION FOR ALLOWANCE. 
Therefore, further action by the applicant is required to avoid abandonment of this application. A proper reply to a 
final rejection under 37 CFR 1.113 may only be either: (1 ) a timely filed amendment which places the application in 
condition for allowance; (2) a timely filed Notice of Appeal (with appeal fee); or (3) a timely filed Request for Continued 
Examination (RCE) in compliance with 37 CFR 1.114. 

• PERIOD FOR REPLY [check either a) or b)] 

a) S The period for reply expires 3_months from the mailing date of the final rejection. 

b) n The period for reply expires on: (1 ) the mailing date of this Advisory Action, or (2) the date set forth in the final rejection, whichever is later. In 

no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of the final rejection. 

ONLY CHECK THIS BOX WHEN THE FIRST REPLY WAS FILED WITHIN TWO MONTHS OF THE FINAL REJECTION. See MPEP 

706.07(f). 

Extensions of time may be obtained under 37 CFR 1.136(a). The date on which the petition under 37 CFR 1.136(a) and the appropriate extension 
fee have been filed is the date for purposes of determining the period of extension and the corresponding amount of the fee. The appropriate extension 
fee under 37 CFR 1.17(a) is calculated from: (1) the expiration date of the shortened statutory period for reply originally set in the final Office action; or 
(2) as set forth in (b) above, if checked. Any reply received by the Office later than three months after the mailing date of the final rejection, even if 
timely filed, may reduce any earned patent term adjustment. See 37 CFR 1.704(b). 

1 0 A Notice of Appeal was filed on . Appellant's Brief must be filed within the period set forth in 

37 CFR 1.192(a), or any extension thereof (37 CFR 1.191(d)), to avoid dismissal of the appeal. 

2. n The proposed amendment(s) will not be entered because: 

(a) □ they raise new issues that would require further consideration and/or search (see NOTE below); 

(b) □ they raise the issue of new matter (see Note below); 

(c) □ they are not deemed to place the application in better form for appeal by materially reducing or simplifying the 

issues for appeal; and/or 

(d) □ they present additional claims without canceling a corresponding number of finally rejected claims. 

NOTE: . 

3. n Applicant's reply has overcome the following rejection(s): . 

4. n Newly proposed or amended claim(s) would be allowable if submitted in a separate, timely filed amendment 

canceling the non-allowable claim(s). 

5. ^ The a)n affidavit. b)\Z\ exhibit, or c)^ request for reconsideration has been considered but does NOT place the 

application in condition for allowance because: ApDlicant's arguments not persuasive (see Detailed Action) , 

6. n The affidavit or exhibit will NOT be considered because it is not directed SOLELY to issues which were newly 

raised by the Examiner in the final rejection. 

7. ^ For purposes of Appeal, the proposed amendment(s) a)n will not be entered or h)M will be entered and an 

explanation of how the new or amended claims would be rejected is provided below or appended. 

The status of the claim(s) is (or will be) as follows: 

Claim(s) allowed: . 

Claim(s) objected to: . 

Claim(s) rejected: 1-24 . 

Claim(s) withdrawn from consideration: . 

8. n The drawing correction filed on is a)\3 approved or b)^ disapproved by the Examiner. 

9. D Note the attached Information Disclosure Statement(s)( PTO-1449) Paper No(s). ^ 7 ^^^^P'^'^'^^ 

10.13 Other: attached Notice of References Cited (PTO-892) . ^^^^^^IX^ 

WILLIAM A. CUCHLINSKI, JR. 
SUPERVISORY PATENT EXAMINER 
TECHNOLOGY CENTER 3^0 

U.S. Patent and Trademark Office 

PTOL-303 (Rev. 1 1 -03) Advisory Action Part of Paper No. 1 001 04 
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DETAILED ACTION 



Response to Arguments 

1. Applicant's arguments filed 07/16/04 have been fully considered but they are not 
persuasive. 

2. Regarding claims 1,9,16,17, and 27 rejected under 35 U.S.C. 1 02(b) as being 
anticipated by Hill et al. (U.S. Pat. No. 5,51,197), Applicant asserts that Hill did not 
suggest a system wherein each message gate is configured for sending and receiving 
messages in a data representation language. Applicant acknowledges that the stub 
and proxy objects disclosed by Hill implemented remote procedure calls, and further 
that Hill described a remote procedure call (RPC) mechanism. Applicant concludes 
from this that Examiner is incorrect in the interpretation that Hill disclosed 
communicating messages in a data representation language, coupled with the assertion 
that "such [RPC] mechanisms are specifically not based on data representation 
languages." However, it is noted by Examiner that the it was in fact known in the prior 
art that RPC mechanisms did utilize data representation languages, as described by 
Sun Microsystems, Inc. standard for data representation described in RFC 1014 
(Network Working Group, Request for Comments: 1014, "XDR: External Data 
Representation Standard", Sun Microsystems, Inc., June 1987). RFC 1014 disclosed 
the data representation language XDR, which was used in Remote Procedure Call 
protocols, such as Sun RPC, to describe the format of their data (see p. 1 , 
"Introduction"). Thus, Examiner submits that Hill undoubtedly disclosed sending and 
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receiving messages in a data representation language as RPC mechanisms were 
clearly known to rely on the use of data representation languages. Furthermore, 
Examiner maintains that the concept of communicating messages in a data 
representation language as broadly claimed relates to nothing more than a standard 
method or format of the messages communicated. Hill disclosed such a limitation, 
stating that stub channels utilized a certain protocol to communicate (see column 20, 
lines 29-31), thus disclosing communication of messages in a data representation 
language. Finally, Applicant asserts that data representation languages were distinctly 
different from sending messages in stubs, proxies, RMI, etc., and that they were used to 
represent or describe data in documents. In response to applicant's argument that the 
references fail to show certain features of applicant's invention, it is noted that the 
features upon which applicant relies (i.e., the use of data representation languages to 
represent or describe data in documents) are not recited in the rejected claim(s). 
Although the claims are interpreted in light of the specification, limitations from the 
specification are not read, into the claims. See In re Van Geuns, 988 F.2d 1 181 , 26 
USPQ2d 1057 (Fed. Cir. 1993). 

3. Regarding claims 1-4, 8-12, 15, 17-20, and 23 rejected under 35 U.S.C. 102(b) 
as being anticipated by Serlet et al. (U.S. Pat No, 5,481,721), Applicant asserts that 
there is clearly no disclosure in Serlet of a system wherein each message gate is 
configured for sending and receiving messages for one of the clients in a data 
representation language. Examiner maintains that the concept of communicating 
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messages in a data representation language as broadly claimed relates to nothing more 
than a standard method or format of the messages communicated. Serlet disclosed 
such a limitation, stating that messages sent between a sender and receiver must be 
encoded in a form understandable by both sides, providing a type of protocol for 
communicating data (see column 12, lines 21-30). Additionally, Applicant notes that the 
Mach message of Serlet contained "a header followed by zero or more data objects." 
Examiner submits that a header suggests a representation of the data objects that 
follow it, describing precisely a data representation language, defined in RFC 1014 to 
be a "language [allowing] one to describe intricate data formats in a concise manner" 
(see p. 1, Introduction). The Mach message of Serlet containing a header followed by 
data objects clearly constitutes a concise packaging of data formats as would be 
recognized by one of ordinary skill in the art. Furthermore, Applicant acknowledges the 
use of C data types in Serlet. Examiner submits that this reads upon the broad concept 
of a data representation language, further evident in RFC 1014 where it was disclosed 
that The XDR [data representation] language itself is similar to the C language". 
Applicant further states that a data representation language is a specific type of 
language used for describing documents, not messages for a programmatic interface as 
in Serlet. In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., the use of data representation languages to describe documents) are not recited in 
the rejected claim(s). Although the claims are interpreted in light of the specification. 
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limitations from the specification are not read into the claims. See In re Van Geuns, 988 
F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

4, Regarding claims 1-4, 8-12, 15, 17-20, and 23 rejected under 35 U.S.C. 102(e) 
as being anticipated by Marcos et al. (U.S. Pat. No. 6,347,342), Applicant asserts that 
Marcos did not teach or suggest the use of a data representation language. Applicant 
acknowledges that Marcos taught using a distributed object model or protocol to fonA/ard 
messages, and further the use of code that would "encode and decode an operation 
and its parameters into a compacted message format". Applicant concludes from this 
that Marcos did not teach the use of a data representation language, but Examiner 
submits that this precisely describes the broadly claimed concept of a data 
representation language. Examiner maintains that the concept of communicating 
messages in a data representation language as broadly claimed relates to nothing more 
than a standard method or format of the messages communicated. Thus, as Marcos 
disclosed the use of a compacted message format and protocol, Marcos clearly reads 
upon the broad concept as claimed. Furthermore, as RFC 1014 defined a data 
representation language to provide a way of describing "data formats in a concise 
manner", the compacted message format used by Marcos without a doubt suggests the 
use of a data representation language. Applicant contends that a data representation 
language differs from sending messages using OLE/COM, CORBA, etc., but it is noted 
that these features upon which applicant relies are not recited in the rejected claim(s). 
Although the claims are interpreted in light of the specification, limitations from the 
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specification are not read into the clainns. See In re Van Geuns, 988 F.2d 1 181 , 26 
USPQ2d 1057 (Fed. Cir. 1993). Applicant asserts that Examiner's arguments amount 
to stating that sending messages in a data representation language is inherent in 
Marcos' teaching, but Examiner can find no such instance in previous arguments or 
rejections. Regardless, it has been shown above that Marcos undoubtedly teaches the 
broad concept of sending messages in a data representation language as claimed. 

5. Applicant further asserts that Marcos failed to teach verifying messages 
according to a data representation language message schema in regards to claim 2. 
Examiner maintains that in its broadest sense, a data representation language message 
schema relates to nothing more than a set format for communicating data that 
messages must adhere to in order for a process to interpret them. Marcos taught the 
use of such a format, stating that objects could communicate using specific data types, 
thus providing a message schema (see column 15, line 60 through column 16, line 55). 
Furthermore, as acknowledged by Applicant, Marcos taught comparing the type of an 
argument from one object model with an expected type of another object model. 
Examiner submits that this clearly suggests the verification of these data types. 

6. Regarding claims 1, 6-9. 14-17, and 22-24 rejected under 35 U.S.C. 102(b) as 
being anticipated by Kingdon (U.S. Pat. No. 5,349,642), Applicant asserts that Kingdon 
did not teach the use of a data representation language. Applicant acknowledges that 
Kingdon taught using a specific message packet format consisting of a header, code, 
and data, and concludes that Kingdon's message packet format is clearly very different 
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from a data representation language. Examiner disagrees, as it is not clear from this 
how the teachings of Kingdon are very different from a data representation language. 
Examiner maintains that a data representation language as claimed is broadly 
interpreted as a standard format or method for communicating data. Kingdon disclosed 
communicating messages in packets created with a specific format (see column 2, lines 
16-49; column 5, lines 25-36). This is also in line with the definition of a data 
representation language from RFC 1014, which states that a data representation 
language describes "data formats in a concise manner" (see p. 1, Introduction). A 
message packet format would have been understood by one of ordinary skill in the art 
as a concise manner in which to represent the message data. Thus, Examiner submits 
that Kingdon without a doubt taught the broad concept of a data representation 
language as claimed. Applicant's argument provides no more than a mere assertion 
that sending messages in a data representation language is distinctly different from 
sending messages using Kingdon's unique message packet format, and is not 
persuasive. 

7. Regarding claims 5, 13, and 21 rejected under 35 U.S.C. 103(a) as being 
unpatentable over Marcos in view of Bergman et al. (U.S. Pat. No. 6,564,263), Applicant 
traverses the rejection as addressed below, 

8. Applicant asserts that the rejection is unsupported by the cited art for at least the 
reasons given above in regard to their respective independent claims. Applicant also 
states that there is no teaching in Marcos of verifying messages according to an XML 
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schema. In response to applicant's arguments against the references individually, one 
cannot show nonobviousness by attacking references individually where the rejections 
are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 
1986). 

9. Regardless, in response to Applicant's assertion that it would make no sense in 
Marcos to verify message according to a data representation language message 
schema, Examiner submits that Marcos clearly suggests such a broad concept as 
recited above in regards to the rejection under 35 U.S.C. 102(e). 

10. Applicant acknowledges that Bergman describes XML as useful in representing 
data and relationships between different versions of content, but traverses the rejection 
under the assertion that it would not be useful for programmatic messaging. However, 
Examiner submits that the provision in Marcos to "encode and decode an operation and 
its parameters into a compacted message format" is clearly a way of representing data 
content, regardless of whether the content was a method invocation as suggested by 
Applicant. Applicant further generally contends the use of an XML schema in Bergman, 
and recognizes that Bergman uses a data representation that captures "all possible 
modalities (e.g. features, characteristics, semantics, metadata, etc.) that may arise in 
different applications or events". However, Examiner submits that this data 
representation format disclosed by Bergman clearly included the use of an XML schema 
(see column 6, lines 47-48). 
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Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

RFC 1014 (Network Working Group, Request for Comments: 1014, "XDR: 
External Data Representation Standard", Sun Microsystems, Inc., June 1987) disclosed 
the Sun Microsystems, Inc. language known as XDR for description, encoding, and 
representation of data used in such remote procedure call protocols such as Sun RPC. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Joseph R Maniwang whose telephone number is (703) 
305-3179. The examiner can normally be reached on Mon-Fri 8:00-4:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William A Cuchlinski can be reached on (703)308-3873. The fax phone 
number for the organization where this application or proceeding is assigned is 703- 
872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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